1. Field of Invention
The present invention relates to a method and apparatus for providing L1 signalling to support the known hybrid automatic repeat request (HARQ) protocol (L1 retransmissions) in an uplink from user equipment (UE) to a receiving node for operating in a wireless network such as, for example, a third generation partnership project (3GPP) wireless network.
2. Description of Related Art
FIG. 1A shows the UE communicating with one or more receiving nodes, such as nodes B1, B2 (e.g. base stations), via an uplink and a downlink in a third generation partnership project (3GPP) wireless network generally indicated as 10. The UE communicates with the receiving nodes B1, B2 via a dedicated channel (DCH), which is also known as an uplink DCH that includes a dedicated physical data channel (DPDCH) and a dedicated physical control channel (DPCCH) for transporting packet data, as shown by way of example in FIG. 1B.
In FIG. 1B, the known uplink DCH structure has 15 slots over a 10 millisecond (ms) radio frame. Each slot, e.g. slot 3, of the physical control channel (DPCCH) includes a pilot field (PILOT), a transport format combination indicator (TFCI) field, a feedback information bits field (FBI) and a transmission power control (TPC) field. Typically, the physical control channel (DPCCH) is transmitted continuously and rate information is sent with the TFCI, which includes information on the data rate of the current DPDCH frame, which includes the packet data in the form of 2560 chips as shown.
As an enhancement for the uplink transmission, a physical/MAC layer retransmission mechanism has been proposed. The idea is that the receiving Node B would acknowledge the correctly received blocks (send ACK) and request retransmission of the incorrectly received blocks (send NAK) and the transmitting UE would retransmit the requested blocks. Furthermore, a hybrid ARQ protocol with soft combining of the (re)transmitted blocks has been proposed. Soft combining of the blocks (first transmission and retransmissions) requires that the information bits of the combined blocks are the same. The channel coded bits (i.e., the bits actually sent in the channel) of the first and retransmissions can be different (e.g., the code words could be punctured in a different way).
However, there is a problem in the art if during an uplink transmission the number of channel bits changes between a previous or earlier transmission and a new transmission. In this case, the currently used TFCI, which tells the transport format for known rel99 transport channels, is not giving enough information. This is because the TFCI currently assumes that there is always a fixed mapping between a certain number of information bits to a certain number of channel bits, when using the current rules from the specifications.
In the prior art, the TFCI is an index to a transport format combination set (TFCS) which includes all the possible/allowed transport format combinations (TFC) for the present connection. For each transport channel a set of transport formats (TF) is defined. The transport format defines the transport block size (TBS) and the transport block set size (TBSS) as dynamic attributes (that can change from TTI to TTI) and transmission time interval (TTI), error correction scheme (e.g., turbo code, code rate and rate matching attribute) and size of CRC as semi-static attributes (that are not changed from TTI to TTI and which can only be changed via radio link reconfiguration). A physical layer can multiplex several transport channels. The TFCS defines which TFCs are allowed, i.e., in practice, which are the allowed transport channel data rate combinations. Once TFC is selected (in the transmitter), the TFCI is a pointer which tells the selected TFC for the receiver.
In the prior art, the TFCI defines the number of information bits for each transport channel (TBS and TBSS). Together with the other transport format (e.g., rate matching) parameters defined by the TF to the UE and rules on how these are used are given in the specifications, the UE knows how many channel bits the total number of information bits in each transport format combination will be mapped to. In a similar way, the receiving node knows how to do the decoding—mapping the channel bits back to information bits—when it gets the TFCI in each frame along with the data.
If the HARQ (L1 retransmissions) protocol is used, there can be different redundancy versions in different retransmissions, which means that the TFCI, together with the rate matching parameters, will no longer necessarily mean a fixed mapping between a certain number of information bits and a certain number of channel bits. This is because the transport format of some other transport channel may change in the next frame, while the retransmission for this transport channel still continues. This means that the number of channel bits might have either increased or decreased for the transport channel for which the retransmission have not yet been completed. Thus there has to be either some new rules in the specifications, or some additional L1 signaling bits sent together with the retransmission, so that the receiving side knows how to decode it.
It has been proposed already in the 3GPP, that there are separate L1 signaling bits (6-8) which tell the number of information bits for that transport channel which uses HARQ.
Then the idea is that the receiving node can first calculate the number of channel bits reserved for a certain transport channel in a certain transport format combination with the help of TFCI and rate matching parameters, in the way as defined in the known rel99 protocol. Then, if the newly defined L1 signaling bits are informing the number of information bits in that frame for that transport channel, then the receiving node knows how to do the decoding, since the coding rate (including both turbo coding and rate matching) in the retransmission is then:
      Coding    ⁢                  ⁢    rate    =      number    ⁢                  ⁢    of    ⁢                  ⁢    information    ⁢                  ⁢    bits    ⁢                  ⁢    per    ⁢                  ⁢    transport    ⁢                  ⁢          channel      /      number        ⁢                  ⁢    of    ⁢                  ⁢    channel    ⁢                  ⁢    bits    ⁢                  ⁢    per    ⁢                  ⁢    transport    ⁢                  ⁢    channel  
In HSDPA, 6 bits are used for telling the transport block size. These bits are sent on HS-SCCH (High Speed Shared Control Channel). If the modulation scheme and/or the number of channelization codes used is changed a lot for the retransmission, then it is not possible to tell the transport block size with these 6 bits. Therefore, in HSDPA, one 6 bit word (111111) is reserved to tell that transport block size is not given in this control message and instead the transport block size from an earlier transmission should be used.
One disadvantage of this approach is that it requires 6-8 bits, which represents a large overhead percentage of the transport channel.